J'utilise ma nouvelle configuration Neovim basé sur lazy.nvim et je n'arrive pas à faire fonctionner eslint dans mon projet Value Props.

J'ai essayé :

eslint-lsp et j'ai un message d'erreur, qui m'indique qu'il ne trouve pas de fichier de configuration. Je me demande si il ne supporte pas format .eslintrc.yaml 🤔.
eslint_d.js : quand je consulte le resélutat retournée par LSPInfo, je constate que eslint_d n'est pas lancé, je ne sais pas pourquoi 🤔.

Je souhaite que mon instance Neovim lance précisément le eslint configuré dans mon projet.
J'ai commencé à faire de recherche à propos de ce que j'utilisais avant, c'est à dire null-ls.nvim et je constate que ce projet est archivé.

Je constate que le projet null-ls.nvim continue à vivre à travers le fork nommé none-ls.nvim.

Je lis dans ce thread que plusieurs personnes conseillent : conform.nvim.

Lightweight yet powerful formatter plugin for Neovim

Je comprends que conform.nvim propose une fonctionnalité de formatage mais pas de "linting". Mais ici je vois qu'il supporte eslint_d 🤔.

En lisant ce thread j'ai beaucoup de difficulté à me faire un avis entre "conform+mvim-lint" versus "null-ls".

#JaiDécidé de tester conform.nvim + nvim-lint.

Après 1h de difficulté avec nvim-lint., #JaiDécidé par pragmatisme d'utiliser none-ls.nvim.

https://github.com/stephane-klein/dotfiles/commit/dc781db2deefaefe0d96d6160baf0d05eae39812

#JaiPublié le playground https://github.com/stephane-klein/mermaid-sveltekit-playground parce que j'ai besoin de faire une intégration Mermaid dans mon projet Value Props.

Ce playground n'a que peu d'intérêt pour le moment, mis à part de confirmer que je n'ai pas eu de difficulté à initialiser Mermaid dans un projet SvelteKit.

Finalement, contraiment à ce que j'avais décidé ici, je n'ai pas utilisé Convict dans mon application Value Props propulsé par SvelteKit.

J'ai "simplement" utilisé la vite-plugin-environment pour définir la valeur par défaut des variables d'environnement de configuration utilisées par l'application.

Exemple :

// vite.config.js
import { defineConfig } from "vite";
import EnvironmentPlugin from 'vite-plugin-environment'
import { sveltekit } from "@sveltejs/kit/vite";

export default defineConfig({
    plugins: [
        EnvironmentPlugin({
            POSTGRES_URL: "postgres://webapp:password@localhost:5432/myapp",
            Y_WEBSOCKET_URL: "ws://localhost:1234",
            SMTP_HOST: "127.0.0.1",
            SMTP_POST: 1025,
            SECRET: "secret"
        }),
        sveltekit()
    ]
});;

Et voici un exemple d'utilisation de ces paramètres de configuration :

// src/lib/server/db.js
import postgres from "postgres";

const sql = postgres(process.env.POSTGRES_URL);

export default sql;

Rien de plus, je n'ai ni utilisé Convict ni dotenv, j'ai pu suivre le principe KISS.

Dans l'application web que je développe pour Value Props, je n'utilise actuellement aucune librairie de configuration pour l'app.

J'utilise uniquement process.env.CONFIG_PARAM || "default value".

En contexte, cela ressemble à ceci.

import nodemailer from "nodemailer";

let transporter;

if (process.env?.SMTP_USER && process.env?.SMTP_PASS) {
    transporter = nodemailer.createTransport({
        host: process.env.SMTP_HOST || "127.0.0.1",
        port: process.env.SMTP_POST || 1025,
        secure: true,
        auth: {
            user: process.env.SMTP_USER,
            pass: process.env.SMTP_PASS
        }
    });
} else {
    transporter = nodemailer.createTransport({
        host: process.env.SMTP_HOST || "127.0.0.1",
        port: process.env.SMTP_POST || 1025,
        secure: false
    });
}

export default transporter;

Je commence maintenant à utiliser des paramètres de configuration à différents endroits. Conséquence, je me dis que c'est peut-être maintenant le bon moment pour utiliser une librairie de configuration du type Convict.

Pourquoi j'ai cité Convict ? Parce que c'était le choix que j'avais fait en 2019, dans le projet gibbon-mail.

#JeMeDemande qu'elle est en 2024, la librairie [Javascript] de type environment-variables, configuration-management la plus populaire actuellement.

Pour répondre à cette question, j'ai commencé à faire une recherche sur npm trends et il m'a proposé la suggestion suivante config vs configstore vs convict vs cross-env vs dotenv

dotenv semble se détacher assez franchement.

dotenv et cross-env sont listés dans Delightful Node.js packages and resources.

Je constate que cross-env est abandonné et conseille ici de migrer vers env-cmd.

Je vais demander avis à des amis, mais pour le moment, je pense que je vais utiliser dotenv.

Quelque heure plus tard :

En faisant la recheche suivant sur le subreddit Svelte : "markdown" #JaiDécouvert ici la librairie carta :

A lightweight, fast and extensible Svelte Markdown editor and viewer.

La démo se trouve ici : https://beartocode.github.io/carta/

#JeMeDemande si je dois tester cette librairie pour réaliser l'objectif du projet Projet -1 "CodeMirror, autocomplétion, Svelte" 🤔.

J'ai regardé le code source de l'extension Slash et j'ai l'impression que je pourrais m'inspirer de cette implémentation pour créer une extension permettant d'implémenter un "sélécteur de ressource", "à la" Obsidian pour le projet Value Props 🤔.

Dans l'application web de mon projet Value Props, j'utilise la librairie sveltekit-i19n qui propose la fonctionnalité suivante :

Module-based – your translations are loaded for visited pages only (and only once!)

Actuellement, j'ai configuré les modules suivants :

❯ tree src/lib/translations
src/lib/translations
├── en
│   ├── all_data.json
│   ├── buttons.json
│   ├── login.json
│   ├── menu.json
│   ├── my_password.json
│   ├── my_preferences.json
│   ├── question_answers.json
│   ├── question_setup.json
│   ├── question_status.json
│   ├── space_data.json
│   ├── space_edit.json
│   ├── space.json
│   ├── space_members.json
│   ├── space_questions.json
│   ├── spaces.json
│   ├── space_slides.json
│   └── space_status.json
├── fr
│   ├── all_data.json
│   ├── buttons.json
│   ├── login.json
│   ├── menu.json
│   ├── my_password.json
│   ├── my_preferences.json
│   ├── question_answers.json
│   ├── question_setup.json
│   ├── question_status.json
│   ├── space_data.json
│   ├── space_edit.json
│   ├── space.json
│   ├── space_members.json
│   ├── space_questions.json
│   ├── spaces.json
│   ├── space_slides.json
│   └── space_status.json
├── index.js
├── lang.json
└── README.md

3 directories, 37 files

Je viens à nouveau de me casser la tête parce que j'ai besoin d'une traduction présente dans le module space_data dans une page qui ne fait pas partie de ce module.
Cela m'arrive très très souvent et je m'en veux, je n'ai pas respecté le principe YAGNI !

Dès le début d'l'implémentation de cette application, j'ai voulu faire les choses "bien" et j'ai commencé à utiliser la fonctionnalité "module" de la librairie !

Je suis persuadé que c'est une optimisation inutile pour le moment. Le découpage en module est difficile.

Encore une expérience qui me confirme que je dois toujours suivre par défaut le principe suivant du Zen of Python :

Flat is better than nested.

Je pense me créer pour ce projet une tâche de dette technique, de refactoring dont le but sera de migrer tous les modules vers un seul module — un seul fichier).

Seulement, le jour où je travaillerai sur la performance de chargement des pages, je réfléchirai à un découpage "intelligent" des traductions en modules.

Value Props

Journaux liées à cette note :